You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Physical planning needs to distinguish summaries rebuilt from complete input from summaries kept current by applying updates. That choice is independent of the logical post-ASAP summary expression.
Before this PR
The post-ASAP type layer had no shared vocabulary for the selected summary construction mode. Downstream lifecycle planning and DAG export therefore could not carry this decision explicitly.
After this PR
SummaryMaintenanceMode represents the two physical choices:
DirectBuild: rebuild from complete input when a value is needed.
Incremental: create state once and apply arriving changes.
The mode intentionally does not live on SummaryNode: one logical summary candidate may use different modes for different workload deployments. A following lifecycle PR attaches the selected mode to the physical deployment guarantee and exports it in the post-ASAP DAG.
Scope
Adds and re-exports SummaryMaintenanceMode.
Provides stable export names.
Does not add execution timing/data representation axes.
Does not duplicate pre-ASAP exact operators or add post-ASAP composition policy.
Lifecycle integration continues in #312, then #316–#319 and #313. Exact
aggregations remain SummaryAgg; other exact pre-ASAP operators keep their
existing definitions through KeepPreAsap when no summary binding applies.
Current-main integration review: this PR is not ready to merge as-is after #295 and #299. The conflict is architectural rather than mechanical. #295 now owns the canonical recurrence vocabulary (recurrence::{CostRate, EvaluationRate, UpdateRate, Horizon}) and recurrence-aware selection APIs, while this branch independently introduces duplicate CostRate/EvaluationRate types and a second recurring-cost path in cost_model.rs. #299 now also owns nested-summary legality through ResultGuarantee/AccuracyModel; phase validation must compose with that model rather than independently rejecting or admitting the same nested candidates. Please rebase on current main, reuse the recurrence types and profiles instead of defining parallel units, and make exact composition preserve/propagate the guarantees introduced by #299. The merged implementation should retain the conservative missing-statistics fallback and phase tests from this PR.
horizon-normalized lifecycle costs, capability/phase validation, assumptions, and structured rejection reasons
materialize_with_lifecycles bridge from this PR's GlobalSelection to plan + state deployments
Validation: workspace check, workload/lifecycle/accuracy tests, all PromQL and SQL frontend tests, and all 11 exact_composition integration tests pass.
Addressed the four follow-up review findings in e117dcb:
lifecycle planning now takes an explicit WorkloadDemand binding, so unrelated workload entries cannot create false reuse for a target
recurrence profiles require an explicit root-to-workload-entry index mapping instead of assuming batch/repeating container order
scheduled evaluation rates count only executions inside the optimization horizon
future-dated data evidence and demand estimates are not considered fresh
Added regression coverage for all four cases. Local validation passes: 5 workload tests, all 237 asap-aware-mapping tests, all 11 exact-composition integration tests, workspace strict Clippy, rustfmt, and diff checks.
zzylol
changed the title
feat(post-asap): compose exact operators with summary plans across explicit update/readout boundaries (#171)
feat: model query workloads, data workloads, and summary lifecycle maintenance
Aug 29, 2026
Addressed the second code-and-doc review in ec714b6:
lifecycle-aware materialization now compares aggregate summary deployment cost with raw recomputation and can fall back to KeepPreAsap
per-summary incremental-update/delete capabilities gate maintained lifecycles; moving real-time windows require deletion support
prepared state is legal only when every bound consumer is predictable and covered by the declared window
empty and duplicate WorkloadDemand bindings are rejected
docs now distinguish implemented latency/provenance behavior from future integrations, update the stale glossary-gap table, and state the remaining broader sibling-candidate search boundary
Regression coverage was added for raw fallback, unsupported deletion, mixed predictable/ad-hoc consumers, and invalid bindings. Local strict Clippy, rustfmt, 241 mapping tests, 5 workload tests, and 11 exact-composition integration tests pass.
zzylol
changed the title
feat: model query workloads, data workloads, and summary lifecycle maintenance
feat: plan query/data workloads and phase-aware summary lifecycles
Aug 29, 2026
zzylol
changed the title
feat: plan query/data workloads and phase-aware summary lifecycles
feat: plan query/data workloads with generic phase-aware summary lifecycles
Aug 29, 2026
zzylol
changed the title
feat: plan query/data workloads with generic phase-aware summary lifecycles
feat: generalize query/data workloads and summary lifecycle maintenance
Aug 29, 2026
zzylol
changed the title
feat: generalize query/data workloads and summary lifecycle maintenance
feat(post-asap): compose exact operators across update/readout boundaries
Aug 29, 2026
zzylol
changed the title
feat(post-asap): compose exact operators across update/readout boundaries
feat(post-asap): model and validate execution phases
Aug 29, 2026
zzylol
changed the title
feat(post-asap): model and validate execution phases
feat(post-asap): model and validate value domains
Aug 30, 2026
zzylol
changed the title
feat(post-asap): model and validate value domains
feat(post-asap): model and validate execution data states
Aug 30, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
Physical planning needs to distinguish summaries rebuilt from complete input from summaries kept current by applying updates. That choice is independent of the logical post-ASAP summary expression.
Before this PR
The post-ASAP type layer had no shared vocabulary for the selected summary construction mode. Downstream lifecycle planning and DAG export therefore could not carry this decision explicitly.
After this PR
SummaryMaintenanceModerepresents the two physical choices:DirectBuild: rebuild from complete input when a value is needed.Incremental: create state once and apply arriving changes.The mode intentionally does not live on
SummaryNode: one logical summary candidate may use different modes for different workload deployments. A following lifecycle PR attaches the selected mode to the physical deployment guarantee and exports it in the post-ASAP DAG.Scope
SummaryMaintenanceMode.Verification
cargo test -p asap-types summary_maintenancecargo clippy -p asap-types --all-targets -- -D warningsStack
Lifecycle integration continues in #312, then #316–#319 and #313. Exact
aggregations remain
SummaryAgg; other exact pre-ASAP operators keep theirexisting definitions through
KeepPreAsapwhen no summary binding applies.